Skip to main content

What are software metrics? Explain different software metrics.

Software Metrics: Definition and Importance​

Software metrics are quantitative measures of the characteristics of software processes, products, or projects. They provide objective data to help monitor, evaluate, and improve software development activities and the resulting software products.

Software metrics are important for several reasons:

  1. Objective Measurement: They provide quantitative data for decision-making rather than relying on intuition or subjective assessments.
  2. Process Improvement: They help identify bottlenecks, inefficiencies, and areas for improvement.
  3. Project Management: They aid in planning, tracking progress, and allocating resources effectively.
  4. Quality Assurance: They help assess and ensure software quality throughout the development lifecycle.
  5. Prediction and Estimation: They provide historical data for more accurate future estimations.
  6. Communication: They facilitate clear communication among stakeholders about project status and product attributes.

Classification of Software Metrics​

Software metrics can be classified in several ways based on what they measure and how they are used:

1. Based on What They Measure​

a. Process Metrics​

Process metrics measure characteristics of the software development process itself.

Purpose: To evaluate and improve the efficiency and effectiveness of development activities.

Examples:

  • Development effort (person-hours)
  • Development time (calendar time)
  • Defect detection rate
  • Requirements volatility
  • Code churn (rate of code changes)
  • Build frequency
  • Deployment frequency
  • Lead time (time from idea to production)

b. Product Metrics​

Product metrics measure characteristics of the software product or deliverables.

Purpose: To assess the quality and characteristics of the software being produced.

Examples:

  • Code size (lines of code, function points)
  • Complexity metrics (cyclomatic complexity, weighted methods per class)
  • Defect density
  • Test coverage
  • Code duplication
  • Documentation adequacy
  • Performance metrics (response time, throughput)

c. Project Metrics​

Project metrics measure characteristics of the overall project.

Purpose: To monitor project health, progress, and resource utilization.

Examples:

  • Schedule variance (planned vs. actual completion)
  • Cost variance (planned vs. actual costs)
  • Team velocity
  • Resource utilization
  • Risk exposure
  • Stakeholder satisfaction

2. Based on When They Are Used​

a. Predictive Metrics​

Predictive metrics are used to forecast or estimate future characteristics or outcomes.

Purpose: To support planning, decision-making, and risk management.

Examples:

  • Function points (to estimate effort)
  • Historical velocity (to predict sprint capacity)
  • Defect prediction models
  • Effort estimation models

b. Descriptive Metrics​

Descriptive metrics measure the current state or historical performance.

Purpose: To understand current status and historical trends.

Examples:

  • Current defect count
  • Actual development time
  • Test pass rate
  • Code coverage achieved

3. Based on Objectivity​

a. Objective Metrics​

Objective metrics are based on direct measurement and not influenced by personal judgment.

Purpose: To provide unbiased measurements.

Examples:

  • Lines of code
  • Number of defects
  • Build time
  • Test execution time

b. Subjective Metrics​

Subjective metrics involve human judgment or perception.

Purpose: To capture aspects that may be difficult to measure directly.

Examples:

  • Code readability ratings
  • User satisfaction scores
  • Maintainability assessments
  • Team morale surveys

Key Software Metrics by Category​

1. Size Metrics​

Size metrics quantify the volume or magnitude of software artifacts.

a. Lines of Code (LOC)​

Definition: Count of the lines in the source code, often excluding comments and blank lines (SLOC - Source Lines of Code).

Usage:

  • Estimating effort and cost
  • Normalizing other metrics (e.g., defects per KLOC)
  • Tracking project growth

Advantages:

  • Easy to measure
  • Intuitive to understand
  • Widely used

Limitations:

  • Varies by programming language
  • Influenced by coding style
  • Doesn't reflect functionality or complexity well

Example: A module with 5,000 lines of code might be estimated to require approximately 500 person-hours based on historical productivity data of 10 LOC per person-hour.

b. Function Points (FP)​

Definition: A measure of software size based on functionality delivered, independent of implementation technology.

Components:

  • External inputs (user inputs)
  • External outputs (reports, screens)
  • External inquiries (interactive queries)
  • Internal logical files (main data stores)
  • External interface files (data shared with other systems)

Usage:

  • Estimating development effort
  • Measuring productivity
  • Comparing projects across different technologies

Advantages:

  • Language and technology independent
  • Focuses on functionality from user perspective
  • Better for comparing dissimilar systems

Limitations:

  • Subjective elements in counting
  • Requires trained counters
  • More complex to calculate than LOC

Example: A system with 5 external inputs (3 simple, 2 complex), 4 external outputs (all average), 3 external inquiries (2 simple, 1 average), 4 internal logical files (1 simple, 2 average, 1 complex), and 2 external interface files (both simple) would yield approximately 100 function points.

c. Story Points​

Definition: A relative measure of effort, complexity, and uncertainty used in Agile methodologies.

Usage:

  • Sprint planning
  • Measuring team velocity
  • Tracking progress

Advantages:

  • Accounts for complexity, not just size
  • Team-specific and contextual
  • Accommodates uncertainty

Limitations:

  • Not comparable across teams
  • Subjective estimation
  • Requires team calibration

Example: A team assigns 8 story points to a feature that involves creating a new user authentication system, while assigning 3 story points to a simpler feature for adding sorting functionality to a table.

2. Complexity Metrics​

Complexity metrics measure how intricate or complicated the software is, which affects maintainability, testability, and error-proneness.

a. Cyclomatic Complexity​

Definition: A measure of the number of linearly independent paths through a program's source code, based on the control flow graph.

Calculation: M = E - N + 2P, where:

  • E = Number of edges in the graph
  • N = Number of nodes in the graph
  • P = Number of connected components

Simplified calculation: Number of decision points + 1

Usage:

  • Identifying complex methods that need refactoring
  • Test case planning (minimum number of test cases)
  • Assessing maintainability

Interpretation:

  • 1-10: Simple, low risk
  • 11-20: Moderate complexity, moderate risk
  • 21-50: Complex, high risk

  • 50: Untestable, very high risk

Example:

public int calculateDiscount(Customer customer, double purchaseAmount) {
    // Cyclomatic complexity = 4
    int discount = 0;
    
    if (customer.isPreferred()) {
        if (purchaseAmount > 1000) {
            discount = 15;
        } else {
            discount = 10;
        }
    } else {
        if (purchaseAmount > 1000) {
            discount = 10;
        } else {
            discount = 5;
        }
    }
    
    return discount;
}

b. Halstead Complexity Measures​

Definition: A set of metrics based on the number of operators and operands in the code.

Basic measures:

  • n1 = number of distinct operators
  • n2 = number of distinct operands
  • N1 = total number of operators
  • N2 = total number of operands

Derived measures:

  • Program vocabulary: n = n1 + n2
  • Program length: N = N1 + N2
  • Volume: V = N × log2(n)
  • Difficulty: D = (n1/2) × (N2/n2)
  • Effort: E = D × V

Usage:

  • Assessing maintainability
  • Predicting error rates
  • Estimating implementation effort

Example: For the expression a = b + c * d, we have:

  • Operators: =, +, * (n1 = 3)
  • Operands: a, b, c, d (n2 = 4)
  • Total operators: 3 (N1 = 3)
  • Total operands: 4 (N2 = 4)
  • Program vocabulary: n = 7
  • Program length: N = 7
  • Volume: V = 7 × log2(7) ≈ 19.65
  • Difficulty: D = (3/2) × (4/4) = 1.5
  • Effort: E = 1.5 × 19.65 = 29.48

c. Weighted Methods per Class (WMC)​

Definition: The sum of the complexities of all methods in a class, often using cyclomatic complexity as the weight.

Usage:

  • Identifying overly complex classes
  • Assessing maintainability of object-oriented code
  • Identifying candidates for refactoring

Interpretation:

  • Low WMC (< 20): Good, maintainable class
  • Medium WMC (20-50): Moderate complexity, consider refactoring
  • High WMC (> 50): Excessive complexity, should be refactored

Example: A class with 5 methods having cyclomatic complexities of 3, 5, 2, 4, and 6 would have a WMC of 20.

3. Object-Oriented Metrics​

These metrics are specifically designed for object-oriented software and measure aspects like inheritance, encapsulation, and coupling.

a. Coupling Between Objects (CBO)​

Definition: Count of the number of other classes to which a class is coupled (i.e., it uses methods or attributes of those classes).

Usage:

  • Assessing class independence
  • Identifying highly coupled classes
  • Predicting maintenance difficulty

Interpretation:

  • Low CBO (< 5): Good, independent class
  • Medium CBO (5-15): Moderate coupling
  • High CBO (> 15): Excessive coupling, refactor

Example: A class that imports and uses methods from 7 other classes has a CBO of 7.

b. Depth of Inheritance Tree (DIT)​

Definition: The maximum length of the path from a class to the root of the inheritance tree.

Usage:

  • Assessing complexity due to inheritance
  • Identifying potential method overriding issues
  • Understanding class hierarchy

Interpretation:

  • Low DIT (1-2): Simple inheritance, easy to understand
  • Medium DIT (3-5): Moderate inheritance depth
  • High DIT (> 5): Excessive inheritance, potential for confusion

Example:

Object
 └── Component
     └── Container
         └── Panel
             └── MyCustomPanel (DIT = 4)

c. Lack of Cohesion in Methods (LCOM)​

Definition: Measures the degree to which methods within a class are related to each other. Several variations exist (LCOM1, LCOM2, LCOM3, etc.).

Basic calculation (LCOM1): Number of pairs of methods that don't share instance variables minus number of pairs that do.

Usage:

  • Identifying classes with poor cohesion
  • Finding classes that should be split
  • Assessing single responsibility principle adherence

Interpretation:

  • Low LCOM: Good cohesion, methods work together
  • High LCOM: Poor cohesion, consider refactoring

Example: A class with methods that all work on different class attributes would have high LCOM, suggesting it should be split into multiple classes.

4. Quality Metrics​

Quality metrics assess various aspects of software quality, such as reliability, maintainability, and usability.

a. Defect Metrics​

Definition: Measures related to the number, density, and characteristics of defects in the software.

Key metrics:

  • Defect count: Total number of defects
  • Defect density: Defects per unit size (e.g., per KLOC or per function point)
  • Defect removal efficiency (DRE): Percentage of defects found before delivery
  • Defect age: Time between defect introduction and detection
  • Defect distribution: Categorization by severity, type, component, etc.

Usage:

  • Assessing software quality
  • Identifying problematic areas
  • Evaluating testing effectiveness
  • Predicting maintenance effort

Example: A system with 50 defects in 10,000 lines of code has a defect density of 5 defects per KLOC.

b. Test Coverage Metrics​

Definition: Measures of how much of the code is exercised by tests.

Key metrics:

  • Statement coverage: Percentage of executable statements executed
  • Branch coverage: Percentage of branches executed
  • Path coverage: Percentage of possible paths executed
  • Function coverage: Percentage of functions called
  • Condition coverage: Percentage of boolean sub-expressions evaluated to both true and false

Usage:

  • Assessing testing thoroughness
  • Identifying untested code
  • Setting quality gates

Example:

public int max(int a, int b) {
    if (a > b) {  // Branch 1
        return a;
    } else {      // Branch 2
        return b;
    }
}

// Test with a=5, b=3 executes Branch 1 only
// Branch coverage = 50%
// To achieve 100% branch coverage, need another test with a ≤ b

c. Maintainability Index​

Definition: A composite metric that indicates how maintainable (easy to support and change) the software is.

Calculation:

MI = 171 - 5.2 * ln(HV) - 0.23 * CC - 16.2 * ln(LOC)

Where:

  • HV = Halstead Volume
  • CC = Cyclomatic Complexity
  • LOC = Lines of Code

Usage:

  • Assessing maintenance difficulty
  • Comparing maintainability across components
  • Setting maintainability thresholds

Interpretation:

  • 85-100: Highly maintainable
  • 65-85: Moderately maintainable
  • Below 65: Difficult to maintain

Example: A module with Halstead Volume of 1000, Cyclomatic Complexity of 15, and 200 LOC would have a Maintainability Index of approximately 75, indicating moderate maintainability.

5. Process Metrics​

Process metrics measure aspects of the development process rather than the product itself.

a. Lead Time and Cycle Time​

Definitions:

  • Lead Time: Time from when a request is made to when it is delivered
  • Cycle Time: Time from when work begins on a request to when it is delivered

Usage:

  • Measuring process efficiency
  • Identifying bottlenecks
  • Tracking process improvements

Example: If a feature request is received on January 1, development starts on January 10, and it's delivered on January 20:

  • Lead Time = 19 days
  • Cycle Time = 10 days

b. Sprint Velocity​

Definition: Amount of work completed in a sprint, typically measured in story points.

Usage:

  • Sprint planning
  • Capacity forecasting
  • Tracking team productivity

Example: A team that completes user stories totaling 30 story points in a two-week sprint has a velocity of 30 points per sprint.

c. Deployment Frequency​

Definition: How often software is deployed to production.

Usage:

  • Measuring DevOps maturity
  • Assessing continuous delivery capabilities
  • Tracking improvement in deployment pipeline

Example: Moving from monthly deployments to daily deployments indicates significant improvement in deployment automation and process efficiency.

d. Change Failure Rate​

Definition: Percentage of changes that result in degraded service or require remediation.

Usage:

  • Measuring deployment quality
  • Assessing release process effectiveness
  • Identifying needs for improved testing

Example: If 5 out of 20 deployments in a month resulted in incidents requiring fixes, the change failure rate would be 25%.

6. Project Metrics​

Project metrics focus on overall project management aspects.

a. Schedule Variance (SV)​

Definition: Difference between the planned schedule and the actual progress.

Calculation: SV = Earned Value - Planned Value

Usage:

  • Tracking project progress
  • Identifying schedule slippage
  • Forecasting completion dates

Example: If the planned value of work at a point in time is $100,000, but the earned value (value of work actually completed) is $80,000, then SV = -$20,000, indicating the project is behind schedule.

b. Cost Variance (CV)​

Definition: Difference between the budgeted cost and the actual cost.

Calculation: CV = Earned Value - Actual Cost

Usage:

  • Tracking project costs
  • Identifying budget overruns
  • Forecasting final costs

Example: If the earned value of work completed is $80,000, but the actual cost incurred is $90,000, then CV = -$10,000, indicating the project is over budget.

c. Requirements Stability Index​

Definition: Measure of how requirements change over time.

Calculation:

RSI = (1 - (Requirements Added + Requirements Modified + Requirements Deleted) / Total Requirements) × 100%

Usage:

  • Assessing requirements volatility
  • Predicting potential scope creep
  • Evaluating requirements gathering effectiveness

Example: If a project starts with 100 requirements, and during development 10 are added, 15 are modified, and 5 are deleted, the RSI would be:

RSI = (1 - (10 + 15 + 5) / 100) × 100% = 70%

This indicates moderate requirements stability.

Implementing Software Metrics Programs​

To effectively use software metrics in an organization, a systematic approach is needed:

1. Goal-Question-Metric (GQM) Approach​

A systematic approach to selecting metrics based on goals:

  1. Define Goals: What are you trying to achieve?
  2. Formulate Questions: What questions need to be answered to achieve the goals?
  3. Identify Metrics: What metrics will answer these questions?

Example:

  • Goal: Improve software maintainability
  • Question: How complex is our codebase?
  • Metrics: Cyclomatic complexity, Maintainability Index, Code churn

2. Establishing a Metrics Program​

Steps for implementing an effective metrics program:

  1. Define objectives: Determine what you want to achieve with metrics
  2. Select metrics: Choose metrics that align with objectives
  3. Establish baselines: Measure current performance as a reference point
  4. Set targets: Define improvement goals
  5. Implement collection: Automate data collection where possible
  6. Analyze and report: Regularly review and communicate findings
  7. Take action: Use metrics to drive improvements
  8. Refine approach: Periodically review and adjust metrics

3. Common Pitfalls to Avoid​

  • Measuring too much: Focus on a few key metrics rather than tracking everything
  • Metrics as targets: Avoid optimizing for the metric at the expense of actual goals
  • Ignoring context: Consider the specific project, team, and environment
  • Punitive use: Don't use metrics to punish individuals or teams
  • Neglecting human factors: Don't forget that development is a human activity
  • Over-reliance on automation: Automated tools can't capture everything

Tools for Software Metrics Collection and Analysis​

Various tools are available to help collect and analyze software metrics:

1. Static Analysis Tools​

  • SonarQube: Comprehensive code quality platform
  • ESLint/TSLint: JavaScript/TypeScript linting with complexity metrics
  • PMD: Source code analyzer for Java
  • NDepend: Advanced .NET code metrics tool

2. Version Control Metrics​

  • Git Analytics: Commits, merge requests, contributors
  • GitPrime/Pluralsight Flow: Developer productivity analytics
  • CodeScene: Behavioral code analysis from version control data

3. Project Management Metrics​

  • Jira: Sprint velocity, burndown charts, cycle time
  • Azure DevOps: Work item tracking, team velocity
  • ClickUp/Asana: Task completion metrics, team productivity

4. Test Coverage Tools​

  • JaCoCo: Java code coverage
  • Istanbul/NYC: JavaScript code coverage
  • Coverlet: .NET code coverage
  • Cobertura: Multi-language coverage tool

5. CI/CD Metrics​

  • Jenkins: Build statistics, test results
  • CircleCI/Travis CI: Build time, success rates
  • GitHub Actions: Workflow metrics
  • TeamCity: Build chain analytics

Conclusion​

Software metrics provide valuable quantitative data for monitoring, evaluating, and improving software development processes and products. By selecting appropriate metrics that align with specific goals, organizations can make more informed decisions, identify areas for improvement, and track progress over time.

The most effective approach to software metrics involves:

  1. Purposeful selection: Choose metrics that directly support your goals
  2. Balanced perspective: Use a combination of product, process, and project metrics
  3. Appropriate context: Interpret metrics within their specific context
  4. Action orientation: Use metrics to drive concrete improvements
  5. Continuous refinement: Regularly reassess which metrics provide the most value

While metrics are powerful tools, they should complement, not replace, human judgment and experience. The ultimate goal is not to optimize for the metrics themselves, but to use them as indicators that guide improvements in software quality, development efficiency, and project outcomes.